home *** CD-ROM | disk | FTP | other *** search
/ Atari Mega Archive 1 / Atari Mega Archive - Volume 1.iso / lists / gem / l_0799 / 418 < prev    next >
Internet Message Format  |  1994-08-27  |  5KB
  1. From: dmj@genie.geis.com
  2. Date: Sun, 12 Jun 94 06:26:00 UTC
  3. To: gem-list@world.std.com
  4. Subject: Hello everyone...
  5. X-Genie-Id: 5647412
  6. X-Genie-From: DMJ
  7. Precedence: bulk
  8.  
  9. It is with a certain trepidation that I post here.  I subscribed to
  10. this list about a week ago, and in that time the list has accumulated
  11. almost 130 messages.  I have to wonder if, while this standardization
  12. effort isn't well-intended, that you've scared off many would-be
  13. participants with the volume of mail here.  (I also have to wonder if
  14. you don't have anything _else_ to do. ;-)
  15.  
  16. [Time passes.]
  17.  
  18. Just finished reading all those messages.  Sheesh.  A few things I'd
  19. like to point out, in case anyone is interested...
  20.  
  21. 1. Some folks on this list *pay* for the mail.  It's *really*
  22. irritating to see an _entire_ message quoted in a response, when
  23. quoting just ONE LINE will do.  If you're going to take the time to
  24. respond, why don't you take the time to figure out which portion of
  25. the message sums up what you're responding to, and quote just that
  26. part (please)?  Anyone who is following the list will probably be
  27. able to tell what it is you're discussing.  In the same vein, is it
  28. really necessary to have 10-line signature blocks?
  29.  
  30. 2. Is it absolutely necessary for everyone to respond with an "I
  31. agree to this" message (which I've seen quite a bit of)?  If you're
  32. not going to add something useful to the topic being discussed, why
  33. answer?
  34.  
  35. Okay, enough steam vented.  There were a few things discussed this
  36. past week that I thought I'd like to comment on.
  37.  
  38.  - ??????.SYS
  39.  
  40. It has been suggested by more than one person that this file be used
  41. as more than a keyboard shortcut configuration file.  As long as only
  42. "global" information is being stored here, that's fine--but any
  43. application-specific information should NOT be stored in a system-wide
  44. configuration file.
  45.  
  46. I also dislike the idea of _yet_another_ file sitting in the root
  47. directory of my boot partition.  I have too many files there as it is,
  48. because software refuses to intelligently look elsewhere for the
  49. files.  I would not be opposed to some environmental variable being
  50. used to define a path where configuration files could be kept;
  51. SHORTCUT.SYS (or whatever) could be placed there, and
  52. application-specific configuration files could be placed there too.
  53.  
  54. And I think .SYS is a bad extension for this file.  Keep in mind that
  55. this is something the _user_ will be editing.  Don't scare them away!
  56. Every time I see a .SYS file, I think of CONFIG.SYS (from DOS),
  57. ASSIGN.SYS (from GDOS), or driver .SYS files (which aren't
  58. user-editable files).  To me, .CNF or .INF would be a better choice.
  59.  
  60. (And when you're discussing what goes in this file, don't forget that
  61. the user has to be able to figure out how to construct it!  Please,
  62. just because it makes sense to a programmer doesn't mean it will make
  63. sense to the average user--and that IS your target here, isn't it?)
  64.  
  65.  - Why have a standard, if you have a key-definition file.
  66.  
  67. I think Tim Miller asked this question.  Personally, I think it's a
  68. valid question.  IF we come up with a standard key-definition file,
  69. this provides the user with a way to redefine any key they like--for
  70. any program they like.  Why should you, or anyone else, tell me what I
  71. should use as my "default"--when any user who cares to will already
  72. have default keys selected, and my program would read and use these
  73. keys *automatically* if the key-definition file is present?  (I do not
  74. ask this to be antagonistic; I'm asking a sincere question.)  Not to
  75. mention the fact that if I can't find some mnemonic that helps me
  76. remember a keyboard shortcut, it isn't a "shortcut": it's work.
  77. CTRL-U doesn't mean a damn thing to me, but CTRL-W sure does.
  78.  
  79. Also, when you quote something is "standard", remember there are lots
  80. of different "standards".  I'd wager 99% of the US Atari users don't
  81. care one bit about what the German standard for keyboard shortcuts
  82. are... and like me, if they can't find something that helps them
  83. remember the keyboard shortcuts, it won't be helping them--it will be
  84. hindering them.
  85.  
  86.  - Wasting a cookie jar slot...
  87.  
  88. Somebody mentioned a cookie in the cookie jar would be "wasting a
  89. slot".  Wasting an 8-byte slot?  Was this a serious comment?  The
  90. cookie jar can be expanded at any time; Atari documented how to do
  91. this when they documented the cookie jar in the first place.  Not only
  92. that, but I've always found the cookie jar to be an immensely useful
  93. tool in finding pointers to software's internal data structures or
  94. obtaining system-wide information.  I think it's a much "cleaner"
  95. approach than many methods I've seen for obtaining this kind of
  96. information.
  97.  
  98. Well, that should do it for now.  I hope the volume on this list stays
  99. at a manageable level--otherwise I will unsubscribe.  And if I'm not a
  100. subscriber, I seriously doubt I'll be following any standard
  101. "accepted" by the group.
  102.  
  103.  -+- Damien M. Jones -+- dmj software -+- dmj@genie.geis.com -+-
  104.  
  105.